\chapter{Структура базы данных}
\label{chap:db}

\section{Логическая модель данных}
В силу требования к гибкости структуры данных было принято решение реализовать вместо классической реляционной модели базы данных, в которой каждой сущности предметной области ставится в соответствие некоторая таблица, модификацию так называемой EAV модели.

EAV модель (от англ. Entity-Attribute-Value Model), \textit{модель Сущность-Атрибут-Значение}~--- это структура хранения данных в базе, при которой отдельно хранятся сами сущности, их атрибуты и значения этих атрибутов для конкретных сущностей. Таким образом, для хранения любых данных с любыми атрибутами из любой предметной области достаточно трёх таблиц: сущности, атрибуты и значения. Пример логической модели базы данных для этого случая можно наблюдать на рисунке \ref{pic:eav}. Здесь и далее используем для демонстрации ER-моделей нотацию IDEF1X.

\begin{figure}[h!]
  \centering
  \includegraphics[width=0.9\linewidth]{resources/eav}
  \caption{Общая диаграмма EAV модели}
  \label{pic:eav}
\end{figure}

Такая модель не учитывает типы сущностей и не позволяет моделировать их классы. Кроме того, значение атрибута всегда имеет строковый тип. Для решения этих проблем вводят таблицу типов, которые могут наследовать друг от друга. Теперь сущности и атрибуты имеют некоторый тип. Именно в таком виде EAV модель обычно используется на практике. Соответствующая ER-модель изображена на рисунке \ref{pic:eav_type}.

\begin{figure}[h!]
  \centering
  \includegraphics[width=\linewidth]{resources/eav_type}
  \caption{EAV модель}
  \label{pic:eav_type}
\end{figure}

Такая модель отличается высокой гибкостью, о чём свидетельствует тот факт, что она позволяет добавлять новые классы сущностей и атрибуты прямо во время работы приложения, не нарушая её, и нет необходимости переписывать код при этом. Единственный недостаток такой модели --- высокая нагрузка на базу данных, так как все сущности по сути хранятся в одной таблице.

Чтобы воспользоваться гибкостью EAV модели и избежать её недостатков мы несколько модифицировали её для нашей предметной области. Будем рассматривать три группы сущностей, реально присутствующих в университете (и не только в нём).
\begin{enumerate}
\item Персоны (Person).
\item Группы (Group).
\item События (Event).
\end{enumerate}

Утверждается, что с помощью этих трёх сущностей можно смоделировать всё, что происходит в университете. Действительно, если опустить технические подробности, назначение университета --- объединять людей (студентов и преподавателей) в группы (потоки, факультеты), чтобы с ними происходили некоторые события (обучение программированию и другим не менее важным наукам). Для каждой из этих сущностей заведём по 4 таблицы EAV модели, кроме того учтём, что в событиях могут принимать участия как группы, так и отдельные персоны. Также учтем, что персоны могут играть ту или иную роль в событии (например, персона <<студент Иван Иванов>> сыграла роль <<двоечник>> на событии <<экзамен по математическому анализу>>). Окончательная ER-модель нашей структуры данных представлена на рисунке \ref{pic:erm}

\begin{figure}[h!]
  \centering
  \includegraphics[width=\linewidth]{resources/erm_new}
  \caption{ER-модель структуры данных}
  \label{pic:erm}
\end{figure}

\section{Физическая модель данных}
При описании физической модели следует учитывать, что при реализации приложения использовалась технология Entity Persistece (ее интерфейсом для Java 2 Enterprise Edition является т. н. Java Persistence API, а реализацией в данном курсовом проекте~--- набор библиотек Hibernate). Суть этой технологии в прозрачном отображении объектов языка программирования в структуры базы данных. Соответственно, промежуточные запросы (создание и удаление таблиц, выборка и изменение данных) генерируются и выполняются конкретной реализацией данной технологии .
Работа программиста в данном случае заключается в написании ряда классов на языке Java, содержащих некоторые поля и ссылки друг на друга. Каждый класс может отображаться в одну или несколько таблиц, поля отображаются на поля таблицы, ссылки~--- на внешние ключи. 
Проиллюстрируем физическую структуру в конечной базе данных, используя SQL-скрипты, сгенерированные на диалекте конечной СУБД PostgreSQL для создания каждой из необходимых таблиц. 
\begin{enumerate}
\item \textbf{Атрибутные типы}
\lstinputlisting[language=SQL]{source/attributetype.sql}
\item \textbf{Тип персоны}
\lstinputlisting[language=SQL]{source/persontype.sql}
\item \textbf{Атрибут персоны}
\lstinputlisting[language=SQL]{source/personattribute.sql}
\item \textbf{Привязка атрибутов персон к типам}
\lstinputlisting[language=SQL]{source/personbindings.sql}
\item \textbf{Персона}
\lstinputlisting[language=SQL]{source/person.sql}
\item \textbf{Параметр персоны}
\lstinputlisting[language=SQL]{source/personparameter.sql}

\item \textbf{Тип группы}
\lstinputlisting[language=SQL]{source/grouptype.sql}
\item \textbf{Атрибут группы}
\lstinputlisting[language=SQL]{source/groupattribute.sql}
\item \textbf{Привязка атрибутов групп к типам}
\lstinputlisting[language=SQL]{source/groupbindings.sql}
\item \textbf{Группа}
\lstinputlisting[language=SQL]{source/group.sql}
\item \textbf{Параметр группы}
\lstinputlisting[language=SQL]{source/groupparameter.sql}

\item \textbf{Тип события}
\lstinputlisting[language=SQL]{source/eventtype.sql}
\item \textbf{Атрибут события}
\lstinputlisting[language=SQL]{source/eventattribute.sql}
\item \textbf{Привязка атрибутов событий к типам}
\lstinputlisting[language=SQL]{source/eventbindings.sql}
\item \textbf{Событие}
\lstinputlisting[language=SQL]{source/event.sql}
\item \textbf{Параметр события}
\lstinputlisting[language=SQL]{source/eventparameter.sql}

\item \textbf{Персоны в группах}
\lstinputlisting[language=SQL]{source/persongroup.sql}
\item \textbf{Группы на событии}
\lstinputlisting[language=SQL]{source/groupevent.sql}
\item \textbf{Персоны на событии}
\lstinputlisting[language=SQL]{source/personevent.sql}
\item \textbf{Роль персоны на событии}
\lstinputlisting[language=SQL]{source/personrole.sql}
\end{enumerate}
